As <a href='http://weblogs.java.net/blog/rbair/archive/2007/01/properties_in_j.html'>Richard Bair points out</a> we <i>really</i> need a way to get a <tt>PropertyDescriptor</tt> easily, i.e. meta data and support for bean properties. For example, we wanna reference bean properties for beans binding in a safe and auto-completable way, as discussed in <a href='http://aptframework.dev.java.net/gooey/beanInfo.html'>Gooey Beans Info</a>.

Since <i>hash</i> <tt>(#)</tt> already denotes fields and methods in the javadoc notation, I reckon <i>hash</i> might be used to get fields and methods, rather than property descriptors. I guess candidates for denoting a <tt>PropertyDescriptor</tt> include a <i>colon</i> e.g. <tt>Person:surname</tt>, and <i>at</i> e.g. <tt>Person@surname</tt>. I was so happy to leave behind  arrows <tt>(->)</tt> when i moved from C to Java, and the thought of now seeing them in Java, is um, too terrible to contemplate ;)

One could argue that if one's favourite IDE supported this notation, e.g. where <tt>Person@surname</tt> is a code-fold of sorts for a static utility invocation e.g. <tt>BeanInfoSupport.getPropertyDescriptor(Person.class, "surname")</tt>, and the IDE supported auto-completion, verification and refactoring of these references, then that would do.

However, a big part of why we need property references, is because these are useful in other APIs, e.g. beans binding and what-not. So they need to be supported in the language if they are to positively influence the design of other APIs.

For instance, APIs might consider referencing properties by <tt>PropertyDescriptor</tt> in addition to property names, in the event of convenient <tt>PropertyDescriptor</tt> references coming into the language e.g. <tt>Person@surname</tt>.

Also, new <tt>PropertyDescriptor</tt> wrappers might be introduced e.g. <tt>BoundPropertyDescriptor</tt>, which wraps a <tt>PropertyDescriptor</tt> together with a specified bean instance, e.g. <tt>theChoosenOne@surname</tt> as opposed to <tt>Person@surname</tt>.

Incidently, on the issue of observable properties, i believe that AOP might be the answer e.g. to fire <tt>PropertyChangeEvent</tt>'s e.g. using dynamic proxies, <a href='http://cglib.sf.net'>CGLIB</a>, or compile-time code generation from annotation processing. 

If property setters and getters are to be generated by the compiler where these don't exist, hopefully this would be performed by a tool which supports code generation from aspects indicated by annotations e.g. a <tt>@JavaBeanAspect</tt> declared on the class.
